Enable coverage when testJvm same as Gradle Daemon JDK or with checkCoverage property#11764
Open
bric3 wants to merge 5 commits into
Open
Enable coverage when testJvm same as Gradle Daemon JDK or with checkCoverage property#11764bric3 wants to merge 5 commits into
testJvm same as Gradle Daemon JDK or with checkCoverage property#11764bric3 wants to merge 5 commits into
Conversation
Contributor
|
🎯 Code Coverage (details) 🔗 Commit SHA: 277da81 | Docs | Datadog PR Page | Give us feedback! |
Contributor
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
mcculls
approved these changes
Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Does This Do
Coverage is now enabled if the
testJvmmatches the daemon JDK (as before), but now also when explicitly requested viacheckCoverageproperty which is consulted when the aggregate test task is being configured, but never was in the test jvm build extension.Note
You can consider this as a hotfix, because
checkCoverageis somewhat an unrelated property to the test jvm constraints plugin, it is a CI concern.At some point this might be refactored to a place with the proper scoped concerns.
Motivation
Code coverage was explicitly disabled when the
testJvmwas run on a different JDK.Coverage was disabled as a side effect of the old multi-JDK test optimization.
When
-PtestJvmwas introduced, the intent was to run the same Gradle Test tasks on another JDK instead of creating separate test tasks per JDK. For those additional JVM runs, Jacoco was explicitly disabled to avoid paying coverage instrumentation cost across the whole compatibility matrix. That made sense when coverage was expected to run only once, on the normal/base test JVM.The problem is that CI later also passed
-PtestJvm=8to the coverage job. While that was mostly harmless, once the daemon moved to a newer JDK, Java 21, the gitlab-ci conditionif [ "$testJvm" == "8" ]; then export GRADLE_PARAMS="-PskipFlakyTests -PcheckCoverage"; fiwas applied, but then made the Java 8 a real test launcher. Which then deactivated jacoco.Additional Notes
Instrumentations were deliberately not covered by jacoco, so only
base_testsjob is affected.History of related changes
testJvmConstraintsGradle extension to replace extra properties #9892Coverage fix PRs
config-utils#11781ProtocolVersiontests and exclude specific classes from coverage #11801